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Abstract. The Eclipse Graphical Modeling (GMF) Framework provides the ma- 
jor approach for implementing visual languages on top of the Eclipse platform. 
GMF relies on a family of modeling languages to describe different aspects of the 
visual language and its implementation in an editor. GMF uses a model-driven 
approach to map the different GMF models to Java code. The framework, as it 
stands, provides very little support for evolution. In particular, there is no support 
for propagating changes from say the domain model (i.e., the abstract syntax of 
the visual language) to other models. We analyze the resulting co-evolution chal- 
lenge, and we provide a transformation-based solution, say GMF model adapters, 
that serve the propagation of abstract-syntax changes based on the interpretation 
of difference models. 



1 Introduction 

"The Eclipse Graphical Modeling Project (GMP) provides a set of generative compo- 
nents and runtime infrastructures for developing graphical editors based on EMF and 
GEE" ifTTIl . Arguably, GMF defines the mainstream approach to graphical editor de- 
velopment within the Eclipse platform. The approach heavily relies on metamodeling 
(based on EMF B7I2I0 . model-to-model and model-to-code transformations, and even 
some forms of code customization, subject to round-tripping considerations. 
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Fig. 1. Snapshot of a simple editor with indications of underlying models. 



The present paper describes research on the co-evolution of GMF editors. In par- 
ticular, we are concerned with the question what and how GMF models need to be co- 
changed in reply to changes of the domain model (say, metamodel, or abstract syntax 
definition) of the editor. Consider, for example, the simple mind-map editor in Fig. [T] 



We have annotated the different panes of the editor with the associated GMF models 
underneath, and also added mentioning of the mapping model which connects the var- 
ious models. (We will describe the architecture of the editor in more detail later.) The 
co-evolution challenge at hand is to "unbreak" the editor upon changes to the domain 
model. The GMF framework does not support such co-evolution. In particular, there are 
no semi-automatic means to unbreak the editor. 

Such lack of co-evolution support somewhat diminishes the original goal of GMF to 
aggressively simplify the development of graphical editors. That is, while it is reason- 
able simple to draft and connect all GMF models from scratch, it is notably difficult to 
evolve an editor through changes of specific GMF models. A recurring focus for evolu- 
tion is the domain model of the editor. Upon domain model changes, the user may notice 
that the editor is broken through unsuccessful runs of some generator, the compiler, or 
the editor itself, and in all cases, subject error messages at a low level of abstraction. 
However, the editor's unsoundness may also go unnoticed for some time. Alternatively, 
the user may attempt to regenerate some models through the available wizards (model- 
to-model transformations of GMF), which however means that the original, possibly 
customized models are lost. 

Contributions 

- We analyze GMF's characteristics in terms of the co-evolution of the various mod- 
els that contribute to a GMF editor. Starting from conceived domain-model changes, 
their implications for the editor itself and other GMF models are identified. 

- We address the resulting co-evolution challenge by complementing GMF's wizard- 
and generator-biased architecture with model-to-model transformations that prop- 
agate changes of the domain model to other models. 

Limitations The existing GMF infrastructure is obviously rather complicated: it is 
a conglomeration of metamodels, libraries, generators, model transformations of in- 
dustrial scale. We cannot claim to provide a full-fledged solution to the co-evolution 
challenge of GMF — this would require full coverage of Ecore, and full understanding 
of the implicit semantics of GMF model dependencies and tools. Nevertheless, we are 
confident that our transformational approach can be scaled incrementally over time to 
cover an increasing number of concrete evolution scenarios. We make available some 
reusable elements of our development publicly (scenarios, transformations, difference 
models, etc.)QThe most critical omission in our methodology is that we do not cover 
currently co-evolution of customization code. This is a very intricate problem by itself, 
to which we hope to contribute through future work. 

Road-map In f|2j we briefly recall the basics of the GMF approach to graphical edi- 
tor development. In Sj3] we study a detailed evolution scenario to systematically reveal 
the co-evolution challenge of GMF. In Sj4] we develop an initial list of domain model 
changes and derive a methodology of co-evolution based on propagating changes to all 
relevant GMF models. In Sj5] we describe the realization of model-to-model transfor- 
mations that are driven by difference models for the domain-model changes. Related 
work is described in f|6| and the paper is concluded in SjT] 

1 http : / / www . emf migrate . org/gmf evolution 
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Fig. 2. The model-driven approach to GMF-based editor development. 



2 GMF in a nutshell 

GMF consists of a generative component (GMF Tooling) and runtime infrastructure 
(GMF Runtime) for developing graphical editors based on the Eclipse Modeling Frame- 
work (EMF) 03 and the Graphical Editing Framework (GEF) The GMF Tooling 
supports a model-driven process (see Fig. [2} for generating a fully functional graphical 
editor based on the GMF Runtime starting from the following models: 

- The domain model is the Ecore-based metamodel (say, abstract syntax) of the lan- 
guage for which representation and editing have to be provided. 

- The graphical definition model contains part of the concrete syntax; it identifies 
graphical elements that may, in fact, be reused for different editors. 

- The tooling definition model contains another part of the concrete syntax; it con- 
tributes to palettes, menus, toolbars, and other periphery of the editor. 

- Conceptually, the aforementioned models are reusable; they do not contain refer- 
ences to each other. It is the mapping model that establishes all links. 

Consider again Fig. [T] which illustrates the role of these models for a simple mind- 
map editorj^Fig.|3]shows all the models involved in the definition and implementation 
of the mind-map editor. In addition to the aforementioned models, two generator models 
are mentioned; they will be explained in a second. 

The domain model of the mind-map editor contains all the concepts and relation- 
ships which have to be implemented in the editor. In the example, the class Mindmap is 
introduced as a container of instances of the classes Topic and Relation. 

Once a domain model is defined, it is possible to automatically produce Java code 
to manage models (instances), say mind maps in our example. To this end an additional 
model, the EMF generator model, is required to control the execution of the EMF gen- 
erator. A uniform version of the extra model can be generated by EMF tooling. The 
model contains the mere list of classes and properties to be considered as well as low- 
level details, e.g., the package prefix for the generated code. 

The graphical definition model consists of a figure gallery including shapes, la- 
bels, lines, etc., and canvas elements to define nodes, connections, compartments, and 
diagram labels. For instance, in the graphical model in Fig. [3] a rectangle named Top- 
icFigure is defined, and it is referred to by the node Topic. A diagram label named 



A mind map is a diagram used to represent words, ideas, tasks, or other items linked to and 
arranged around a central keyword or idea. The initial mind-map editor suffices with "topics" 
and "relations", but some extensions will be applied eventually. 
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Fig. 3. The GMF models and model dependencies for the editor of Fig.[TJ We high- 
light contributions that are related to a selected domain concept: topics. In this manner, 
we show how information about domain concepts is scattered over the various models. 
It is important to notice that most of these recurrences are not actual references; the 
correspondences are name-based. Strong links are only to be found in the mapping and 
the generator models. 



TopicName is also defined. Such graphical elements will be used to specify the graphi- 
cal representations for Topic instances and their names. 

The tooling definition model defines toolbars and other periphery to facilitate the 
management of diagram content. In Fig. [3] the sample model consists of the Topic and 
Relation tools for creating the Topic and Relation elements. 

The mapping model links together the various models. For instance, according to 
the mapping model in Figure [3] Topic elements are created by means of the Creation 
Tool Topic and the graphical representation for them is Node Topic. For each topic the 
corresponding name is also visualized because of the specified Feature Label Mapping 



which relates the attribute name of the class Topic with the diagram label TopicName 
defined in the graphical definition model. 

Once the mapping model is obtained, the GMF Tooling generates (by means of 
a model-to-model transformation) the GMF generator model that is used by a code 
generator to produce the real code of the modeled graphical editor. 

3 GMF's co-evolution challenge 

Using a compound change scenario, we will now demonstrate GMF's co-evolution chal- 
lenge. Overall, the objective is to clarify that domain model changes imply changes of 
other GMF models. Such change propagation is not supported currently by GMF, and 
it is labor-intensive and error-prone, when carried out manually. Conceptually, it turns 
out to be difficult to precisely predict when and how co-changes must be performed. 
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Fig. 4. An evolved mind-map editor with different kinds of topics. 



Consider the enhanced mind-map editor of Fig. [4] Compared to the initial version 
of Fig. [TJ scientific vs. literature topics are distinguished, and topics have a duration 
property in addition to the name property. 

Now consider Fig. [5j it shows the evolved metamodel at the top, and the status of 
the, as yet, unamended mapping model at the bottom. We actually show the mapping 
model as it would appear to the user if it was inspected in Eclipse. Some of the links in 
the mapping model are no longer valid; in fact, they are dangling (c.f., "null"). Through 
extra edges, we show what the links are supposed to be like. 

We get deeper insight into the situation if we comprehend the evolved domain model 
through a series of simple, potentially atomic changes, i) The Topic class was renamed 
to ScientificTopic. ii) The new abstract class NamedElement was added, iii) The at- 
tribute name of the old Topic class was pulled up to the new NamedElement class, iv) 
The attribute duration was added to the NamedElement class, v) The new class Litera- 
tureTopic was added as a further specialization of NamedElement. 

In practice, these changes would have been carried out in an ad-hoc manner through 
free-wheeling editing capabilities of the Ecore editor of Eclipse. Because of these changes, 
the existing mapping model is no longer valid — as shown in Fig. [5] In particular, ref- 
erences to Topic or the attribute name thereof are dangling. The other GMF models are 
equally out-of-sync after these domain model changes. 
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Fig. 5. The domain model for the evolved mind-map editor with the "broken" mapping 
model. 



Incomplete or unsuccessful editor evolution may be signaled in different ways, or 
may, in fact, remain hidden for some time — depending on the specific domain model 
change as well as the usage of GMF tooling. We list obvious and hidden symptoms of 
broken or unsound editors: 

1. The EMF generator or the GMF generator fails (with an error). 

2. The EMF generator or the GMF generator completes with a warning. 

3. The generator for the GMF generator model fails. 

4. The compiler fails on the generated EMF or GMF code. 

5. The editor plugin fails at runtime, e.g., at launch-time. 

6. A GMF model editor reports an error upon opening a GMF model. 

7. The editor plugin apparently executes but misses concepts of the domain. 

8. The editor plugin apparently executes but there are GUI events without handlers. 

Let us consider two specific examples. First, the addition of a new class to the 
domain model, e.g., LiteratureTopic, should probably imply a capability of the editor to 
create instances of the new class. However, such a creation tool would need to be added 
in the mapping and tooling models. Second, the renaming of a class, e.g., the renaming 
of Topic to ScientificTopic, may lead to an editor with certain functionality not having 
any effect because elements are referenced that changed or do not exist anymore in 
the domain model. Both examples are particularly interesting in so far that the editor 
apparently still works, i.e., it is not broken in a straightforward sense. However, we say 
that the editor is unsound; the editor does not meet some obvious expectations. 



Such a distinction of broken vs. not broken but nevertheless unsound also naturally 
relates to a spectrum of strategies for co-changes. A minimalistic strategy would focus 
on unbreaking the editor. That is, co-changes are supposed to bring the editor models 
to a state where no issues are reported at generation, compile or runtime. A best-effort 
strategy would try to bring the editor to a sound state, or as close to it as possible with 
a general (perhaps automated) strategy. 

Consider again the example of adding a new class C: 

Minimalistic strategy The execution of the EMF generator emits a warning, which we take to 
mean that the editor is broken. Hence, we would add the new class C to the EMF generator 
model. This small co-change would be sufficient to re-execute all generators without further 
errors or warnings, and to build and run the editor successfully. The editor would be agnostic 
to the new class though because the mapping and tooling models were not co-changed. 

Best-effort strategy Let us make further assumptions about the added class C. In fact, let us 
assume that C is a concrete class, and it has a superclass S with at least one existing con- 
crete subclass D. In such a case, we may co-change the other GMF models by providing 
management for C based on the replication of the management for D. 

Here we assume that a best-effort strategy may be amenable to an automated trans- 
formation approach in that it does not require any domain-specific insight. The modeler 
will still need to perform additional changes to complete the evolution, i.e., to obtain a 
sound editor. 

4 Changes and co-changes 

Let us discuss and assess a catalog of domain-model changes and associated co-changes 
of other editor models. Obviously, we can depart from catalogs of metamodel changes 
as they are available in the literature, e.g., 1191131 , and previous work by the authors J31- 
Due to space constraints, a selection must be made: it covers atomic changes that are 
needed for the compound scenario of the previous section, completed by a few addi- 
tional ones. Many of the missing changes would refer to technical aspects of the EMF 
implementation, and as such, they do not contribute to the discussion. 



Level 


Description 


1 


Unsound in the sense of being broken; there are reported issues (errors, warnings). 


2 


Unsound in the sense that the editor "obviously" lacks capabilities. 


3 


Sound as far as it can be achieved through automated transformations. 


4 


Sound; established by human evaluation. 



Table 1. Levels of editor soundness along evolution. 



In continuation of the soundness discussion from the previous section, Table[T]iden- 
tifies different levels of soundness for an evolving editor. The idea is here that we assess 
the level of the editor before and after all (automated) co-changes were applied. The 
proposed transformations can never reach Level 4 because it requires genuine evalua- 
tion by the modeler. 

However, we are not just interested in the overall level of the editor, but we also 
want to blame one or more editor models for the editor's unsoundness. In Table [2] we 
list atomic changes with the soundness levels for the editor before and after co-changes, 
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Table 2. Considered Ecore metamodel changes 



and all the indications as to what models are to blame. We use "x" to blame a model 
for causing the editor to be broken, i.e., to be at Level 1. We use "o" and "•" likewise 
for Level 2 and Level 3. 

The EMFGen model is frequently to blame for a broken editor before the co- 
changes; the Graph model is never to blame for a broken editor; the remaining models 
are to blame occasionally for a broken editor. Obviously, there is trend towards less 
blame after the co-changes: no occurrences of "x", more occurrences of In differ- 
ent terms, for all domain-model changes, all other models can be co-changed so that 
the editor is no longer broken. In several cases, we reach Level 3 for the editor. 

There are clearly constellations for which changes cannot be propagated in an au- 
tomated manner that resolves all Level 2 blame. For instance, the metamodel change 
add concrete class does not require a co-changed Graph model as long as some existing 
graphical element can be reused. However, avoidance of Level 2 blame would require 
a manual designation of a new element or genuine selection of a specific element as 
opposed to an automatically chosen element. 

Fig.|6]describes some changes and co-changes in detail. 

5 Automated transformation of GMF models 

We have developed a process for GMF co-evolution which involves automated transfor- 
mations in an essential manner. We describe this process here. We also provide some in- 
sight into the implementation of the involved transformations, which is based on model 
transformations specified in ATL |14|. (The implementation is available publicly — as 
described in the introduction of the paper.) 

Fig. [^summarizes the approach: given two subsequent versions of the same domain 
model their differences are calculated and then represented in a difference model. Such 
differences are then taken as input by different adapters each devoted to the co-change 
of a specific GMF model. Interestingly, the GMFMap and the GMFTool adapters take 



Add empty, concrete class Apart from the EMFGen model, the other ones are not affected; the 
editor simply does not take into account the added class. Thus, modelers cannot create or edit 
instances of the new class. The co-change may replicate the model from existing classes as 
discussed in fJ5] Ultimately, the modeler may need to manually complete the management of 
the new class. 

Add empty, abstract class In comparison to the previous case, the co-change of the EMFGen 
model is fully sufficient since abstract classes cannot be instantiated, and hence, no additional 
functionality is needed in the editor. 

Add specialization The change consists of modifying an existing class by specifying it as spe- 
cialization of another one. In particular, in the simple case of the superclass being empty, this 
modification does not affect any model; thus, no co-changes are required. 

Delete concrete class Deleting an existing class is more problematic since all the GMF models 
except the Graph model are affected. Especially the Mapping model has to be fixed to solve 
possible dangling references to the deleted class. The Tooling model is also co-changed by 
removing the creation tool used to create instances of the deleted class. Even if the model is not 
adapted, the generator model and thus the editor can be generated — even though the palette will 
contain a useless tool without associated functionality. The Graph model can be left unchanged. 
The graphical elements which were used for representing instances of the deleted class, may be 
re-used in the future. 

Rename class Renaming a class requires co-change of the Mapping model which can have, 
as in the case of class deletion, invalid references which have to be fixed by considering the 
new class name. The Graph model does not require any co-change since the graphical elements 
used for the old class can be used even after the rename operation. The Tooling model can be 
left untouched, or alternatively the label and the description of the tool related to the renamed 
class can be modified to reflect the same name. However, even with the same Tooling model, a 
working editor will be generated. 

Add property The strategy for co-change is similar to the addition of new classes. 

Delete property Deleting a property which has a diagrammatic representation requires a co- 
change of the Mapping model in order to fix occurred dangling references. Moreover if some 
tools were available to manage the deleted property, also the Tooling model has to be co- 
changed. As in the case of class removals, the graphical model can be left unchanged. 

Rename property The strategy for co-change is similar to the renaming of classes. 

Move property When a property is moved from one class to another, then dangling references 
may need to be resolved in the Mapping model. If the moved property is managed by means of 
some tools, the Tooling model require co-changes, too. We only offer a simple, generic strategy 
for co-changes: the repaired editor does not consider the moved property. 

Pull up property Given a class hierarchy, a given property is moved from an extended to a base 
class. This modification is similar to the previous one — even though an automatic resolution 
can be provided to co-change Tooling and Mapping models in a satisfactory manner. 

Change property type The EMFGen model is not affected. However, by changing the type of 
a property some dangling references can occur in the Mapping model; their resolution cannot 
be fully automated. Also, if the affected property is managed by some tool, then the Tooling 
model must be co-changed as well. 



Fig. 6. Detailed descriptions of selected changes and co-changes. 




Fig. 7. Overview of the process of co-evolution with automated transformations. 



as input both the GMFMap model and the GMFTool model since the dependencies 
between these two models have to be updated simultaneously. No adapter is provided 
for the Graph model; the discussion of the previous sections suggested that we can 
always reasonable continue with the old model. 



Model-based representation of domain model differences 

We seek the adoption of standard model-driven techniques and tools for their manage- 
ment and to derive in an automatic way the co-changes of the GMF models. To this 
end, the difference metamodel concept, presented by the authors in 0, and already 
adopted in different scenarios including the management of the coupled evolution of 
metamodels and models |3), is leveraged. 

The approach is summarized in Fig. [Hj given two Ecore metamodels, their differ- 
ence conforms to a difference metamodel MMD derived from Ecore by means of the 
MM2MMD transformation. For each class MC of the Ecore metamodel, the additional 
classes AddedMC, DeletedMC, and ChangedMC are generated in the extended Ecore 
metamodel by enabling the representation of the possible modifications that can occur 
on domain models and that can be grouped as follows: 

- additions, new elements are added in the initial metamodel; 

- deletions, some of the existing elements are deleted; 

- changes, some of the existing elements are updated. 
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Fig. 8. Difference metamodel generation 
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Fig. 9. Fragment of the difference model for the evolution scenario of ^3] 

In Fig. [9j a fragment of the difference model representing the changes between the 
domain models in Fig. [3] and Fig. [5] is shown. For some of the reported differences, 
the corresponding properties are shown. For instance, the renaming of the Topic class 
is represented by means of a ChangedEClass instance which has as updated element 
an instance of EClass named LiteratureTopic (see the updatedElement property of the 
changed class Topic shown on the right-hand side of Fig. [9}. The addition of the class 
NamedElement is represented by means of an AddedEClass instance. The move oper- 
ation of the attribute name from the class Topic to the added class NamedElement is 
represented by means of a Change dE Attribute instance which has one EAttribute in- 
stance as updated element with a different value for the eContainingClass property. In 
fact, in the initial version it was Topic (see the second property window) whereas in the 
last one, it is NamedElement (as specified in the third property window). 



Difference Model 




Property 
Abstract 

Application Element 
Name 

Updated Element 



Added EClass NamedElement 
-fy Changed EClass Topic 
EClass LiteratureTopic 
Added EClass ScientificTopic 
Changed EAttribute name 
EAttribute name 




Property 

EContaining Class 
Name 

Updated Element 



Property 



EContaining Class 
Name 



ATL-based implementation of GMF model adapters 

Our prototypical implementation of the GMF model adapters leverages ATL, a QVT 
compliant language which contains a mixture of declarative and imperative constructs. 
In particular, the implementation of the GMF adapters consists of transformation rules 
which copy the given source model to a target one; during this operation they evaluate if 
changes are needed. A number of helpers have been defined; they navigate models and 
perform complex queries on them. Many of the helpers are common to all the adapters, 
and hence, they are available through a library gmfAdaptationLib. Table [3] describes 
some of these helpers. 

Small excerpts of the GMFMap and GMFTool adapters are shown in Listing |1.1| 



and Listing 1.2 respectively. For instance, the AddedSpecializationClassTo... transfor- 
mation rules manage new classes which have been added in the domain model as spe- 
cializations of an existing one. The code excerpts involve the replication strategy that 
we have described in previous sections. More specifically, the AddedSpecialization- 
ClassToNodeMapping rule in Listing [TT| is executed for each match of the source pat- 
tern in lines 4-14 which describes situations like the one we had in the sample scenario 
where the LiteratureTopic class (see si) is added as specialization of an abstract class 
(see s2) which is specialized by another class (see s3). In this case, the Mapping model 



Helper name 


Context 


Return type 


Description 


getEClassInNewMetamodel 


EClass 


EClass 


Given a class of the old metamodel, it re- 
turns the corresponding one in the new 
metamodel. 


getNewContainer 


EAttribute 


EClass 


Given an EAttribute in the old metamodel, 
the corresponding container in the new 
one is retrieved. To this end, the helper 
checks if the EAttribute has been moved 
to a new added class, if not an existing 
class is returned. 


isMoved 


EAttribute 


Boolean 


It checks if the considered EAttribute has 
been moved to another container 


isMovedToAddedEClass 


EAttribute 


Boolean 


It checks if the considered EAttribute has 
been moved to a new added EClass. 


isRenamed 


EAttribute 


Boolean 


It checks if the given EAttribute has been 
renamed. 



Table 3. Some helpers of the gmfAdaptationLib 



is updated by adding a new TopNodeReference and its contained elements (see lines 
20-34) which are copies of those already existing for s3. 



l . . . 

2 rule AddedSpecializat ionClassToNodeMapping 
3 
4 
5 
6 
7 



9 
10 
11 
12 
13 
14 
15 
16 
17 

18 
19 

20 
21 

22 

23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 



from 

Sl: DELTAMM ! AddedEClass , s2 : DELTAMM ! AddedEClass , 
S3: DELTAMM ! ChangedEClass, s4: DELTAMM ! ChangedEAttrlbute, 
s5: DELTAMM! EAttribute 
((not sl. abstract) 
and sl . eSuperTypes->f irst ( ) = s2 
and s2. abstract 

and s3 . updatedElement->f irst (). eSuperTypes->f irst ( ) = s2 
and s4 . updatedElement->f irst ( ) = s5 
and s4 . eContainingClass = s3 
and s5 . eContainingClass = s2 } ) 

using { 

siblingFeatureLabelMapping : GMFMAPMM ! FeatureLabelMapping = s3. 
getNodeMappingFromChangedClass () . labelMappings 

->select(e | e. oclIsTypeOf (GMFMAPMM ! FeatureLabelMapping) ) ->f irst ( ) ; 

to 

tl : GMFMAPMM! TopNodeReference ( 

containmentFeature <- s3 . getTopNodeRef erenceFromChangedClass ( ) . 

containmentFeature . getFeaturelnNewMetamodel ( ) , 
ownedChild <- t2 

) , 

t2 : GMFMAPMM ! NodeMapping ( 

domainMetaElement <- sl . getAddedClassInNewMetamodel ( } , 

relatedDiagrams <- s3 . getNodeMappingFromChangedClass ( ) .relatedDiagrams, 
tool <- sl . name . getNewToolFromTitle ( ) , 

diagramNode <- s3 . getNodeMappingFromChangedClass {). diagramNode 

) , 

t3 : GMFMAPMM! FeatureLabelMapping ( 

diagramLabel <- siblingFeatureLabelMapping . diagramLabel, 
features <- siblingFeatureLabelMapping . f eatures->collect (e I e. 
getFeaturelnNewMetamodel ) 



36} 



Listing 1.1. Fragment of the GMFMap Adapter 



A similar source pattern is used in the rule of Listing 1.2 (lines 4-9) in order to add 



a creation tool for the new added class si to the Tooling model (see lines 15-19). 
l . . . 

2rule AddedSpecializationClassToCreationTool { 
3 

4 from 

5 si: DELTAMM! AddedEClass, s2 : DELTAMM! AddedEClass, s3: DELTAMM IChangedEClass 

6 ( (not si. abstract) 

7 and si . eSuperTypes->f irst ( ) = s2 

8 and s2. abstract 

9 and s3 . updatedElement->f irst ( } . eSuperTypes->f irst ( ) - s2 ) 
10 

11 using { 

12 toolGroup : GMFTOOLMM! ToolGroup = OclUndef ined; 

13 } 
14 

15 to 

16 t : GMFTOOLMM ! Creat ionTool ( 

17 title <- s3 . getToolFromChangedClass () .title . regexReplaceAll (s3 . 

getToolFromChangedClass ( ) .title, si. name), 

18 description <- 'Create new ' + si. name 

19 >, 
20 

21 } 

Listing 1.2. Sample transformation rule of the GMFTool Adapter 



6 Related work 

Graphical model editors In [1|, a number of technologies for the development of 
domain-specific modeling languages (DSMLs) are evaluated; Eclipse (EMF with GEF) 
is covered, but not GMF. The evaluation criteria include language evolution to mean 
the ability to co-evolve models when the domain model changes, and Eclipse receives 
a medium grade here. There is no criterion though that relates to GMF's particular 
characteristics of using multiple editor models. 

Other GMF- or GEF-based frameworks have been proposed. For instance, the Mu- 
vitorKit framework [ 16 1 is based on EMF and GEF and specifically meant as an alterna- 
tive to GMF for the benefit of additional editor capabilities (e.g., multiple panes) as well 
as additional modeling capabilities, thereby requiring less customization of generated 
code. There is also the EuGENia framework [ 15] which raises the level of abstraction in 
GMF-based development by using annotations on the domain model, thereby feeding 
into code generation. We are not aware of any prior effort to propagate changes across 
GMF models. 

The ViatraDSM framework ifTTl replaces GMF in that it allows for versatile map- 
pings between abstract and concrete syntax. Live transformations are leveraged to main- 
tain the coherence of the two models. Our uni-directional, difference-driven transforma- 
tions propagate domain-model changes elsewhere. Our work is specifically targeted at 
the mainstream GMF-based approach with its various models. 



Model consistency The status of GMF models being out-of-sync can be compared to 
the notion of model inconsistency in (UML-based) modeling where different models 
providing different views may require synchronization. For instance, in J6), inconsis- 
tencies between the different diagrammatic forms in UML models are considered, and 
possible fixes are proposed in the form of value changes. In [10], the dependencies be- 
tween models are modeled through triple graph grammars in a manner that enables in- 
cremental model synchronization. Our specific contribution is one of reverse engineer- 
ing: discovering the GMF model dependencies, and making them operational through 
automated transformations. 

Co-evolution of metamodels and models The techniques and the methodology of 
our work are inspired by research on co-evolution in model-driven engineering 1811 81 . 
Much of this work is concerned with co-transforming models in reply to metamodel 
changes. In our work, the focus is on the domain models (metamodels), too, and changes 
are to be propagated to other editor models. Our soundness levels for evolved editors 
relate to transformation properties of 1121191 . Our change scenarios are inspired by 
considerations in 119113 1 for MOF and EMF We leverage difference representations of 
our previous work 13 15 1 . 

7 Concluding remarks 

We have described the challenge of sound evolution for graphical editors based on 
model-driven development with GMF in particular, and we have addressed this chal- 
lenge by a system of co-transformations that propagate changes from domain models 
to the other editor models. 

We have identified a range of options for evolved editors to be unsound, and we have 
described corresponding resolution strategies. Our work is the first attempt to come to 
a similar level of understanding as with the established problem of metamodel/model 
co-evolution, in which case the situation is more clear-cut: models either are not broken, 
or they are broken and can be reasonably resolved in an automated manner, or a well- 
understood problem-specific contribution to the resolution must be provided manually 
or through a heuristic. In the case of co-evolution for editor models, each of the various 
models calls for a designated analysis, and there are intricate inter-model dependencies. 

In our ongoing research, we try to better understand the co-evolution issues and 
associated strategies for the code level of GMF where generated code has been possibly 
customized. Based on preliminary research, we can already report that customization 
is used by some GMF projects extensively, and hence designated co-evolution support 
may provide significant help with real-world editor development. 
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